Upgrading of recurring payment cancellation services

ABSTRACT

A method of reducing chargebacks due to a cancelled recurring payment, wherein the payment occurs within a card-based financial network, and wherein the network includes a database of unauthorized recurring charges and a defined chargeback procedure. The method generally includes the step of upgrading a recurring payment cancellation services file based on predefined occurrences relating to the identifying of cancelled recurring payments.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a divisional application of and claims the benefitof priority to co-pending U.S. application Ser. No. 13/431,291, filed onMar. 27, 2012, which in turn claims the benefit of priority to U.S.Provisional Application No. 61/475,791, filed Apr. 15, 2011, thedisclosures of both of which are incorporated herein by reference intheir entireties for all purposes.

BACKGROUND OF THE INVENTION

The present invention relates to recurring payment cancellation servicesand, more particularly, to a system and method for upgradingcancellation services relating to the identifying of cancelled recurringpayments.

Recurring payments are common in the marketplace. A cardholderpreauthorizes a merchant to automatically bill a credit or debit card ata preset interval (e.g., monthly, quarterly or annually). This istypically done for a matter of convenience for both the cardholder andthe merchant. These payment transactions typically occur withoutincident.

However, changes in the merchant/cardholder relationship can introducechallenges into the process. For example, the cardholder may revokepreauthorization to bill his account due to either a change in paymenttype or discontinuation of a merchant relationship. Although mostmerchants quickly honor the change in the recurring payment billingarrangement, there are times when the merchant does not make therequested change in a timely fashion. In this case, the cardholdercontinues to incur the periodic charge. He then contacts the cardissuer, and requests a refund. This request for a refund results in theissuing bank seeking a chargeback from the merchant bank.

Although a payment network such as the MasterCard Worldwide Networkincludes a procedure for chargebacks, this process nevertheless resultsin cost to the participants, as well as a potential loss of goodwillbetween the issuing back and the cardholder. Continued billing to acardholder's account results in complaints to the issuer's customerservice department, and may even result in the cardholder asking to havehis or her account closed.

To reduce the frequency of chargebacks resulting from cancelledrecurring payments, as well as to maintain the relationship between theissuing bank and its cardholder, a cancellation service can be providedwhereby a database is maintained of unauthorized recurring paymentsassociated with particular cards. An issuing bank can participate insuch a cancellation service by inputting information associated with aparticular card into the database to prevent future unauthorized billingfrom a selected merchant. In this way, the recurring charge is blockedbefore it can appear on the cardholder's bill, thus eliminatingcomplaints from the cardholder, as well as the need for a chargeback bythe issuing bank.

Although databases of cancelled recurring payments are effective inblocking unauthorized recurring payments, the existing systems requirethe issuing bank (or some other authorized entity) to provide thedatabase with the necessary financial data, e.g., account number,merchant identity, merchant bank identity and transaction amount.Typically, this data is manually entered into the database by anemployee of the issuing bank. As a result, the entry of data into thecancellation database can be delayed and/or never completed due to thetime and effort involved with inputting such data.

In addition, some charges are not properly identified as recurringpayments by the submitting merchant. This failure to identify thepayment as a recurring payment can result in the bypassing of thecancellation database during the authorization/clearance process.

There is therefore a need in the art for a system and method forproviding an updated database of cancelled recurring payments forcomparison during the authorization and/or clearance process. There is afurther need in the art for a system and method of identifying cancelledrecurring payments even when the submitted charge is not properlyidentified as a recurring payment.

SUMMARY OF THE INVENTION

The present invention involves a method of reducing chargebacks due to acancelled recurring payment, wherein the payment occurs within acard-based financial network, and wherein the network includes adatabase of unauthorized recurring charges and a defined chargebackprocedure. The method generally includes the step of creating an entrywithin the database during the chargeback procedure when the chargebackprocedure is related to a cancelled recurring payment, whereupon thecancelled recurring payment is subsequently identified in the databaseas an unauthorized recurring charge.

In a preferred embodiment, the method further includes the step ofextracting predefined data associated with the cancelled recurringpayment, wherein the creating step includes the further step ofpopulating a field associated with the database with the predefineddata. Also, the creating step preferably includes the further steps ofcomparing the predefined data associated with the cancelled recurringpayment to file data contained within the database and inputting atleast one item from the predefined data into the database in accordancewith predefined parameters.

The present invention also involves a method of reducing chargebacks dueto a cancelled recurring payment, wherein the payment occurs within acard-based financial network, and wherein the network includes adatabase of unauthorized recurring charges and a defined automaticbilling updating procedure for assigning a new account number to acardholder. The method generally includes the step of updating thedatabase during the automatic billing updating procedure when thenetwork identifies an unauthorized recurring charge in said databaseassociated with said cardholder.

In a preferred embodiment, the method includes the further step ofextracting predefined data associated with the automatic billingupdating procedure, and the updating step includes the further step ofpopulating a field associated with the database with the predefineddata. When the unauthorized recurring charge is associated with an oldaccount number, the updating step preferably includes the further stepof associating the new account number with the old account number in thedatabase, wherein a file is created containing both the old accountnumber and the new account number for subsequent comparison.

The present invention further involves a method for reducing chargebacksdue to a cancelled recurring payment, wherein the payment occurs withina card-based financial network, and wherein the network includes acancellation service, which includes a database of unauthorizedrecurring charges. The method generally includes the steps of receivinga financial processing request identifying a card-based payment withouta recurring payment code, determining whether the issuing bankassociated with the request is a participant within the cancellationservice, comparing data associated with the request to the unauthorizedrecurring charges contained within the database and determining aresponse to the processing request in accordance with predefinedparameters.

In a preferred embodiment, the comparing step provides a plurality ofauthorization comparisons and includes the further step of assigningvalues to each of the authorization comparisons. The authorizationcomparisons are preferably related to selected secondary criteria, whichincludes information relating to at least one of a merchant identity, amerchant size, a length of time a merchant has been doing business, anumber of cancelled recurring payments associated with a merchant, anumber of chargebacks associated with a merchant or a billing date. Thedetermining step preferably includes the further step of combining thevalues, and rejecting the processing request when the combination ofvalues exceeds a predefined threshold, wherein the predefined thresholdis determined by an issuing bank.

In another method for reducing chargebacks due to a cancelled recurringpayment, the method generally includes the steps of receiving afinancial processing request identifying a card-not-present (CNP)transaction, determining whether the issuing bank associated with therequest is a participant within the cancellation service, comparing dataassociated with the request to the unauthorized recurring chargescontained within the database and determining a response to theprocessing request in accordance with predefined parameters.

In a preferred embodiment of this method, the comparing step againprovides a plurality of authorization comparisons, and includes thefurther step of assigning values to each of the authorizationcomparisons, wherein the authorization comparisons are related toselected secondary criteria. The determining step again preferablyincludes the further step of combining the values, and rejecting theprocessing request when the combination of values exceeds a predefinedthreshold, wherein the predefined threshold is determined by an issuingbank. This method is also carried out when the financial processingrequest is received without a recurring payment code.

A preferred form of the method according to the present invention, aswell as other embodiments, objects, features and advantages of thisinvention, will be apparent from the following detailed description ofillustrative embodiments thereof, which is to be read in conjunctionwith the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematical diagram of a card-based payment system;

FIG. 2 is a flow diagram of a file maintenance process for acancellation listing system;

FIG. 3 is a flow diagram of an authorization and clearance process for acard-based transaction;

FIG. 4 is a flow diagram depicting the updating of a recurring paymentcancellation service (RPCS) file during a chargeback process;

FIG. 5 is a flow diagram depicting the updating of a RPCS file during anautomatic billing updating process;

FIG. 6 is a flow diagram of an alternative authorization and clearanceprocess for a card-based transaction; and

FIG. 7 is a flow diagram of still another alternative authorization andclearance process for a card-based transaction.

DETAILED DESCRIPTION OF THE INVENTION

Referring first to FIG. 1, in a typical card-based payment systemtransaction, a cardholder 10 presents his credit/debit card to amerchant 12 for the purchase of goods and/or services. This transactionis indicated by arrow 14. It will be understood that prior to theoccurrence of transaction 14, cardholder 10 was issued a card by issuingbank 16. Moreover, it will be understood that merchant 12 established arelationship with a merchant bank 18, thereby allowing merchant 12 toreceive credit/debit cards as payment for goods and/or services. Themerchant banks and issuing banks may participate in various paymentnetworks, including payment network 20. One such payment network isreferred to as the MasterCard Worldwide Network.

After presentation of a card to merchant 12 by cardholder 10, merchant12 sends an authorization request (indicated by arrow 22) to bank 18. Inturn, bank 18 communicates with network 20 (indicated by arrow 24), andnetwork 20 communicates with the issuing bank 16 (indicated by arrow 26)to determine whether the cardholder is authorized to make thetransaction in question. An approval or disapproval of the authorizationrequest is thereafter transmitted back to merchant 12 (indicated byarrows 28, 30 and 32). Merchant 12 thereafter either completes orcancels the transaction based upon the response to the authorizationrequest.

If transaction 14 is approved, the transaction amount will be sent fromissuing bank 16 through network 20 to bank 18. This transaction amount,minus certain fees charged by both network 20 and bank 18, willthereafter be deposited within a bank account belonging to merchant 12.Issuing bank 16 thereafter bills cardholder 10 (indicated by arrow 34)for the amount of such transaction, and cardholder 10 follows by asubmission of payment(s) (as indicated by arrow 36) to issuing bank 16.This submission of payment(s) (as indicated by arrow 36) by cardholder10 may be automated (e.g., in the case of debit transactions), may beinitiated by the cardholder for the exact amount matching costs ofpurchases during the statement period (e.g., charge cards or creditbalances paid in full), and/or may be submitted (in part or in whole)over a period of time that thereby reflects the costs of the purchasesplus financing charges agreed upon beforehand between the cardholder andthe cardholder's issuing bank (e.g., revolving credit balances.)

When cardholder 10 receives an unauthorized recurring charge, (whether aone-time, or a recurring charge), on his statement, the cardholdercontacts issuing bank 16 (indicated by arrow 38) and requests a refund.Issuing bank 16 then initiates a chargeback (indicated by arrows 40,42), requesting a refund of the payment from merchant bank 18. Thisrefund is provided back to the cardholder (as indicated by arrows 44,46, 48).

Network 20 preferably includes at least one server 49 and at least onedatabase 50. Server 49 may include various computing devices such as amainframe, personal computer (PC), laptop, workstation or the like. Theserver can include a processing device and be configured to implement anauthorization and clearance process, which can be stored in computerstorage associated with the server. The authorization and clearanceprocess can be implemented by the server to prevent and/or reduceunauthorized recurring payments. Database 50 may include computerreadable medium storage technologies such as a floppy drive, hard drive,tape drive, flash drive, optical drive, read-only memory (ROM), randomaccess memory (RAM), and/or the like.

Referring now to FIG. 2, a cancellation listing system 51 of the presentinvention is shown. System 51 is preferably implemented by network 20,and is preferably maintained by the network provider, e.g., MasterCard,or by an independent authorized third party. System 51 preferablyincludes an account management system (AMS) file 52, a recurring paymentcancellation service (RPCS) file 54 and a billing service file 56. AMSfile 52, RPCS file 54 and billing service 56 are preferably stored indatabase 50 of network 20, and processed by server 49. Although FIG. 2depicts AMS file 52, RPCS file 54 and billing service file 56 asseparate discrete files, these separate files could be contained withinone larger file. In one preferred application, the mentioned files arestored within a single storage device as separate files. In anotherpreferred application, RPCS file 54 is a sub-file of AMS file 52.

AMS file 52 is preferably a database of cards which have been flaggedfor non-authorization, e.g., lost or stolen cards, cards in collectionand cards participating in the recurring payment cancellation service.In other words, the AMS file is essentially a negative database. AMSfile 52 preferably communicates with both RPCS file 54 and billingservice file 56. File 56 is associated with the billing of an issuingbank for each card entered into RPCS file 54.

Entering data into AMS file 52, and ultimately into RPCS file 54, may beaccomplished in at least two ways. In the first way, a written request58 is forwarded to the operator of system 51. The written request 58includes the necessary data (e.g., account number, merchant identity,merchant bank identity, transaction amount) to be entered into RPCS file54. The data is thereafter entered into RPCS file 54 by authorizationsupport 60. The second method of inputting data into the RPCS file 54involves the direct input of data by issuing bank 16 (or an authorizedentity). More particularly, issuing bank 16 communicates with a systeminput 62, which then forwards the data through an issuer file 64. Theinput of the data into AMS 52 is depicted by arrows 66, 68, and theconfirmation of the input of such data is depicted by arrows 70, 72. Itis contemplated herein that system input 62 can be accomplished byvarious computing devices such as a mainframe, personal computer (PC),laptop, workstation, handheld device, or the like.

As will be recognized by those skilled in the art, the transactionprocessing of card-based payments include both an authorization side anda clearance side. The authorization side involves the process ofconfirming that the cardholder has a sufficient line of credit to coverthe proposed payment. The clearance side of the transaction involves theprocess of moving funds from the issuing bank to the merchant bank. FIG.3 depicts a transaction processing flow chart showing both theauthorization side and the clearance side of the card-based payment.

Referring to FIG. 3, and to the authorization side of the transaction,an authorization request 74 is submitted by a merchant bank to network20. Network 20 first considers whether the charge included inauthorization request 74 is a recurring payment (76). In this regard,merchants and/or merchant banks preferably indicate a recurring paymentas such by utilizing defined criteria, e.g., an identifying code. If theproposed charge is not a recurring payment transaction, then theprocessing of the authorization request continues at step 78 in ordinaryfashion. However, if the proposed charge is indicated to be a recurringpayment, then network 20 determines whether the issuing bank is anissuer participant (80). If the issuing bank is not an issuerparticipant, then the processing of the transaction continues at step 78in ordinary fashion. If the issuing bank is an issuer participant, thennetwork 20 determines whether the data associated with the proposedcharge defined in the authorization request matches a recurring accountcharge (RAC) blocking criteria (82). This step is indicated at 84, andis accomplished by accessing RPCS file 54. If RAC blocking criteria arenot found, then the processing of the authorization request continues instep 86 in ordinary fashion. If RAC blocking criteria are found, thenthe authorization request is rejected, as indicated by steps 88 and 90.

Turning now to the clearance side of the transaction, a clearingpresentment 92 is submitted to network 20. Network 20 determines whetherclearing presentment 92 involves a recurring payment (94), and if not,directs network 20 to continue processing the clearing presentment atstep 96 in ordinary fashion. If clearing presentment 92 involves arecurring payment, then network 20 determines whether the issuing bankis an issuer participant (98). If the issuing bank is not an issuerparticipant, then network 20 continues processing the clearingpresentment at step 96 in ordinary fashion. If the issuing bank is anissuer participant, then network 20 determines whether the dataassociated with the charge defined in the clearing presentment matchesthe RAC blocking criteria (100). This step is indicated at 102 in FIG.3, and is accomplished by accessing RPCS file 54. If RAC blockingcriteria are not found, then the processing of the clearing presentmentcontinues at step 104 in ordinary fashion. If RAC blocking criteria arefound, then the clearing presentment is rejected at step 106.

At present, the RPCS file maintenance described in FIG. 2 is isolatedfrom the typical chargeback process described with respect to FIG. 1. Inother words, unless the issuing bank ensures that the appropriate datais entered into RPCS file 54 (by either input 62 or written request 58),then the process described in FIG. 3 will be ineffective in identifyingunauthorized recurring charges, and will be unable to reject suchcharges.

Accordingly, one aspect of the present invention is to associate thechargeback process with the RPCS file such that the process ofperforming a chargeback results in the creation of an entry within RPCSfile 54 which will be available for future comparison during steps 82and 100 of the transaction process. This entry in RPCS file 54 can becreated because the chargeback process requires the input of the same orsimilar data required to flag an unauthorized recurring payment, e.g.,the account number, merchant identity, merchant bank identity andtransaction amount.

When issuing bank 16 initiates a chargeback within network 20, thechargeback is preferably associated with RPCS file 54 whereby theserver(s) (e.g., server 49) and database(s) (e.g., database 50) involvedin the chargeback process communicate with RPCS file 54, either directlyor through AMS file 52, to add and/or update the data contained in RPCSfile 54. The association between the chargeback process and RPCS file 54is shown in greater detail in FIG. 4. More particularly, in addition tothe normal steps incurred during a typical chargeback 108, the presentinvention adds the additional step (110) of contacting RPCS file 54 anddetermining whether a match is found in the stored data for the paymentassociated with the chargeback. Step 110 is preferably initiated whenthe chargeback 108 includes a predefined code indicating that suchchargeback is due to a “cancelled recurring” charge. If a match is foundin RPCS file 54 for the payment associated with the chargeback, then theupdating process of RPCS file 54 is discontinued at step 112. If nomatch is found in RPCS file 54 for the payment associated with thechargeback , then RPCS file 54 is updated at step 114 to add the dataassociated with the chargeback to RPCS file 54, e.g., account number,merchant identity, merchant bank identity and transaction amount.

It is contemplated herein that network 20 may also include an automaticbilling updater (ABU) platform 200. ABU platform may be stored indatabase 50, and processed by server 49. ABU platform 200 is used toautomatically maintain the accuracy of account data for account-on-filepayments, including recurring payments, between participating issuers,acquirers and merchants. Another aspect of the present invention is toassociate ABU platform 200 with the RPCS file 54 such that the processof performing an ABU account number change results in the updating ofRPCS file 54. More particularly, the RPCS file 54 can be updated to alsoinclude the new account number provided through the ABU account numberchange. In other words, RPCS file 54 will now include both the old andnew account numbers, such that if a merchant attempts to process anunauthorized recurring payment using the new card number, thetransaction will be flagged and subsequently rejected.

Thus, as shown in FIG. 5, ABU platform 200 creates a file 202 containingboth the old and new account numbers associated with a cardholder. Thesystem then communicates with RPCS 54 to determine whether a listingexists for the old account number (204). If a listing 206 exists, thenthe system can either create a new RPCS listing with the duplicateinformation (208), or update the existing RPCS listing with the newaccount number (210). If no existing RPCS listing is found in step 204,then the process is terminated at step 212.

Although merchants and merchant banks are supposed to indicate recurringcharges by coding such charges in a particular manner, this coding isnot always associated with a recurring payment. The failure to properlycode a payment can result from oversight, error or even intentionalomission. Existing cancellation listing services require the payment tobe identified as a “recurring payment” to trigger the RPCS file inquiry.Accordingly, a merchant may intentionally omit the recurring paymentdesignation to avoid having the transaction denied. The presentinvention further contemplates at least two authorization and clearanceprocesses (as shown in FIGS. 6 and 7) which consider the possibilitythat payments have been improperly labeled, i.e., that a recurringpayment has not been labeled as such.

Turning to the first embodiment shown in FIG. 6, an authorizationrequest 116 is submitted to network 20, which then considers whether thepayment associated with the request is a recurring payment (118). If thesubmitted payment is identified as a recurring payment, then the processcontinues at step 120 as discussed hereinabove with respect to step 76in FIG. 3. However, if the payment associated with authorization request116 is not identified as a recurring payment, then network 20 considerswhether the issuing bank is an issuer participant (122). If the issuingbank is not an issuer participant, then the transaction is continued atstep 124 in ordinary fashion. If the issuing bank is an issuerparticipant, then network 20 determines whether the data associated withthe proposed charge defined in the authorization request matches the RACblocking criteria (126). This step is indicated at 128, and isaccomplished by accessing RPCS file 54. If RAC blocking criteria are notfound, then the processing of the transactions continues at step 130 inordinary fashion. If RAC blocking criteria are found, then the processconsiders certain secondary criteria (131).

In this first embodiment, network 20 considers selected secondarycriteria in step 131 before approving or denying the authorizationrequest. More particularly, the process can be configured to deny theauthorization request at 132 when a predefined number of secondarycriteria are matched, or when a particular weighting of all criteria hasbeen reached. These secondary criteria can include the identity of themerchant, the size of the merchant, the length of time such merchant hasbeen doing business, the number of cancelled recurring paymentsassociated with such merchant, the number of chargebacks associated withsuch merchant, the billing date, etc. It is contemplated that differentsecondary criteria can be assigned different values. It is alsocontemplated that the number of matches necessary to cause anauthorization request to be denied can be targeted and specific to aparticular issuing bank. This can provide the issuing bank with anadditional degree of control over the cards and accounts issued to itscustomers. Considering these additional criteria before denying anauthorization request can reduce the likelihood that a legitimate chargeis denied.

Inasmuch as a card based payment also involves a clearance process, thisprovides the issuing bank with a second opportunity to identify anunauthorized charge. As shown in FIG. 6, clearing presentment 134 issubmitted to network 20. If the payment associated with clearingpresentment 134 is a recurring payment, then the process continues atstep 136 as discussed hereinabove with respect to FIG. 3. However, ifthe payment associated with clearing presentment 134 is not identifiedas a recurring payment then the network considers whether the issuingbank is an issuing participant (138). If the issuing bank is not anissuer participant, then the process continues at step 140 in ordinaryfashion. If the issuing bank is an issuer participant, then network 20determines whether the data associated with the charge defined in theclearing presentment matches the RAC blocking criteria (142). This stepis indicated at 144, and is accomplished by accessing RPCS file 54. IfRAC blocking criteria are not found, then the process continues at step146 in ordinary fashion. If RAC blocking criteria are found, then theclearing process considers certain secondary criteria (147).

In this first embodiment, network 20 considers selected secondarycriteria before approving or denying the presentment request. Moreparticularly, the process can be configured to deny the presentment at148 when a predefined number of secondary criteria are matched, or whena particular weighting of all criteria has been reached. These secondarycriteria can include the identity of the merchant, the size of themerchant, the length of time such merchant has been doing business, thenumber of cancelled recurring payments associated with such merchant,the number of chargebacks associated with such merchant, the billingdate, etc. It is contemplated that different secondary criteria can beassigned different values. It is also contemplated that the number ofmatches necessary to cause a presentment to be denied can be target andspecific to a particular issuing bank. This can provide the issuing bankwith an additional degree of control over the cards and accounts issuedto its customers. Considering these additional criteria before denying apayment request can reduce the likelihood that a legitimate charge isdenied.

Turning to the second embodiment shown in FIG. 7, an authorizationrequest 150 is submitted to network 20, which then considers whether thepayment associated with the request is a card-not-present (CNP)transaction (152). CNP transactions include, among others, the recurringpayments discussed herein. If the submitted payment is not identified asa CNP transaction, then the process continues at step 154 in ordinaryfashion. However, if the payment associated with authorization request150 is identified as a CNP transaction, then network 20 considerswhether the issuing bank is an issuer participant (156). If the issuingbank is not an issuer participant, then the transaction is continued atstep 154 in ordinary fashion. If the issuing bank is an issuerparticipant, then network 20 determines whether the data associated withthe proposed charge defined in the authorization request matches the RACblocking criteria (158). This step is indicated at 160, and isaccomplished by accessing RPCS file 54. If RAC blocking criteria are notfound, then the processing of the transactions continues at step 162 inordinary fashion. If RAC blocking criteria are found, then theauthorization request is rejected at step 164.

Inasmuch as a card based payment also involves a clearance process, thisprovides the issuing bank with a second opportunity to identify anunauthorized charge. As shown in FIG. 7, clearing presentment 166 issubmitted to network 20, which then considers whether the paymentassociated with the presentment is a CNP transaction (168). If thepayment associated with clearing presentment 166 is not identified as aCNP transaction, then the process continues at step 170 in ordinaryfashion. However, if the payment associated with clearing presentment134 is identified as a CNP transaction, then the network considerswhether the issuing bank is an issuer participant (172). If the issuingbank is not an issuer participant, then the process continues at step170 in ordinary fashion. If the issuing bank is an issuer participant,then network 20 determines whether the data associated with the chargedefined in the clearing presentment matches the RAC blocking criteria(174). This step is indicated at 176, and is accomplished by accessingRPCS file 54. If RAC blocking criteria are not found, then the processcontinues at step 178 in ordinary fashion. If RAC blocking criteria arefound, then the clearing presentment is rejected at step 180.

Thus, in this second embodiment, network 20 identifies all CNPtransactions, and automatically checks for matching blocking criteriafor participating issuers—irrespective of how the transaction is coded.In this way, an issuer is more likely to “catch” unauthorized recurringcharges which have not been properly coded as such, whether doneinnocently or intentionally. In other words, if the data associated withthe proposed transaction matches the RAC blocking criteria in the RPCSfile, and the transaction is a CNP transaction, then the authorizationrequest or presentment will be denied.

It will be appreciated that the present invention has been describedherein with reference to certain preferred or exemplary embodiments. Thepreferred or exemplary embodiments described herein may be modified,changed, added to or deviated from without departing from the intent,spirit and scope of the present invention, and it is intended that allsuch additions, modifications, amendments and/or deviations be includedin the scope of the present invention.

1. (canceled)
 2. (canceled)
 3. (canceled)
 4. (canceled)
 5. A method ofreducing chargebacks due to a cancelled recurring payment, said paymentoccurring within a card-based financial network, said network includinga database of unauthorized recurring charges and a defined automaticbilling updating procedure for assigning a new account number to acardholder, the method comprising the steps of: updating said databaseduring said automatic billing updating procedure when said networkidentifies an unauthorized recurring charge in said database associatedwith said cardholder.
 6. The method according to claim 5, comprising thefurther step of extracting predefined data associated with saidautomatic billing updating procedure; and wherein said updating stepincludes the further step of populating a field associated with saiddatabase with said predefined data.
 7. The method according to claim 6,wherein said unauthorized recurring charge is associated with an oldaccount number, and wherein said updating step includes the further stepof associating said new account number with said old account number insaid database.
 8. The method according to claim 7, wherein said updatingstep includes the further step of creating a file containing both saidold account number and said new account number for subsequentcomparison.
 9. A method for reducing chargebacks due to a cancelledrecurring payment, said payment occurring within a card-based financialnetwork, said network including a cancellation service, saidcancellation service including a database of unauthorized recurringcharges, the method comprising the steps of: receiving a financialprocessing request identifying a card-based payment without a recurringpayment code; determining whether the issuing bank associated with saidrequest is a participant within said cancellation service; comparingdata associated with said request to said unauthorized recurring chargescontained within said database; and determining a response to saidprocessing request in accordance with predefined parameters.
 10. Themethod according to claim 9, wherein said comparing step provides aplurality of authorization comparisons, and wherein said comparing stepincludes the further step of assigning values to each of saidauthorization comparisons.
 11. The method according to claim 10, whereinsaid authorization comparisons are related to selected secondarycriteria.
 12. The method according to claim 11, wherein said selectedsecondary criteria comprises information including at least one of amerchant identity, a merchant size, a length of time a merchant has beendoing business, a number of cancelled recurring payments associated witha merchant, a number of chargebacks associated with a merchant or abilling date.
 13. The method according to claim 10, wherein saiddetermining step includes the further step of combining said values, andrejecting said processing request when said combination of valuesexceeds a predefined threshold.
 14. The method according to claim 13,wherein said predefined threshold is determined by an issuing bank. 15.A method for reducing chargebacks due to a cancelled recurring payment,said payment occurring within a card-based financial network, saidnetwork including a cancellation service, said cancellation serviceincluding a database of unauthorized recurring charges, the methodcomprising the steps of: receiving a financial processing requestidentifying a card-not-present (CNP) transaction; determining whetherthe issuing bank associated with said request is a participant withinsaid cancellation service; comparing data associated with said requestto said unauthorized recurring charges contained within said database;and determining a response to said processing request in accordance withpredefined parameters.
 16. The method according to claim 15, whereinsaid comparing step provides a plurality of authorization comparisons,and wherein said comparing step includes the further step of assigningvalues to each of said authorization comparisons.
 17. The methodaccording to claim 16, wherein said authorization comparisons arerelated to selected secondary criteria.
 18. The method according toclaim 16, wherein said determining step includes the further step ofcombining said values, and rejecting said processing request when saidcombination of values exceeds a predefined threshold.
 19. The methodaccording to claim 18, wherein said predefined threshold is determinedby an issuing bank.
 20. The method according to claim 15, wherein saidfinancial processing request is received without a recurring paymentcode.